home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 4 / BBS in a Box - Macintosh - Volume IV (January 1992) (BBS in a Box).iso / Files / Prog / M / MPWGCC (Docs).cpt / Documents / Hacking GCC / Hacking GCC
Encoding:
Text File  |  1990-11-22  |  7.1 KB  |  138 lines  |  [TEXT/MPS ]
  1. FOLDERS AND PATHS
  2.  
  3. The script "BuildGCCStages" assumes that the main GCC folder is one level up from
  4. the folder it was in when executed.  If the script is anywhere else, then you will
  5. need to pass the path to that main folder as a second argument to BuildGCCStages.
  6. I recommend keeping all GCC stuff in a folder separate from MPW, but it's not required.
  7.  
  8. BISON
  9.  
  10. To rebuild GCC from scratch, you must first have Bison; either ensure that Bison
  11. is in one of your Tools folders and that the skeleton parsers "bison.simple"
  12. and "bison.hairy" reside wherever your variable {Libraries} points, or rebuild Bison
  13. by going to the Bison folder and building "bison", then moving the skeleton parsers
  14. to {Libraries}.
  15.  
  16. REBUILDING
  17.  
  18. To do a basic recompilation, type "BuildGCCStages 1".  This will create a new folder
  19. GCC.MPW.s1, copy the necessary files from GCC.MPW, and create "first stage"
  20. (compiled by MPW C) cpp and cc1 tools, which can be put wherever you like.  The
  21. process takes 15-20 minutes on a IIci.  The results are not quite as good as when
  22. GCC compiles itself, but take a lot less time to produce and are fine for testing
  23. changes.
  24.  
  25. To get the best versions, you have to use GCC to compile itself.  Three complete
  26. compilations will be necessary, so do "BuildGCCStages 3".  On a IIci, it will run for
  27. about two hours.  If you say "BuildGCCStages 4" instead, then it will do one more
  28. self-compilation; the fourth-stage compiler should be *completely* identical to the
  29. third stage.  If not, then something is wrong.  In any case, the third stage cpp and
  30. cc1 (in GCC.MPW.s3) are the ones to use (drop them anywhere on your command path).
  31.  
  32. BuildGCCStages needs lots of extra diskspace, about 3Mb/stage over and above
  33. the 8Mb of the source distribution.  Actually, each stage only really needs
  34. the tools built in the previous stage, not the object or temp files, so they
  35. could be deleted to save space.
  36.  
  37. If I'm rebuilding for experimentation, I usually just add GCC.MPW to the front of
  38. my command path, to avoid the confusion of old versions getting used instead.  The
  39. -tools option is also useful for this.
  40.  
  41. Another speedup is to use the "insn" target instead of "cc1" if only the machine
  42. description "md" has been changed.  MPW makefiles have to do all the dependency
  43. checking before starting execution, which means that they can't take advantage of
  44. the fact that most of the insn-* files don't change when md is changed.  However,
  45. if you make "insn" and then "cc1", the makefile will only have to recompile the
  46. insn-* files that were actually changed by making "insn".
  47.  
  48. BUILDING GCC FOR 68000 and/or SANE
  49.  
  50. At present, one of GCC's unresolved bugs requires both -mc68020 and -mc68881 to be
  51. turned on when compiling itself.  GCC is too slow to be particularly attractive on
  52. older/slower Macs anyway, so this didn't seem like a real hardship. If you really
  53. really need a 68000+SANE GCC, but don't care about having it be self-compiled, you
  54. could build the first stage without -mc68020 and -mc68881 and use that; it is a little
  55. slower, and some optimizations are missing, but otherwise works fine.
  56.  
  57. TESTING
  58.  
  59. This is an important step.  The folder Tests has a few programs that are small
  60. enough to look at the assembly code, plus a version of dhrystone.  You should also
  61. try using gC to build the programs in the MPW CExamples folder.  Of course, when
  62. GCC successfully self-compiles, it is severely tested.  For test suites, we have
  63. used the "C Torture Test" (available on various Internet servers) and the commercial
  64. Plum-Hall test suite.
  65.  
  66. RETARGETING TO EXISTING MACHINES
  67.  
  68. To build GCC for other machines, create a folder GCC.<machine> and copy the desired
  69. machine-specific files from the Machines folder.  The copies will be something like
  70.  
  71.     copy :Machines:<machine>.md :GCC.<machine>:md
  72.     copy :Machines:tm-<machine>.h :GCC.<machine>:tm.h
  73.     copy :Machines:out-<machine>.c :GCC.<machine>:aux-output.c
  74.     copy :Machines:xm-<system>.h :GCC.<machine>:config.h
  75.  
  76. If you're working under MPW, then xm-mpw.h is almost always the correct file for
  77. config.h.  However, you should examine the file to be sure (for instance, if you
  78. don't want to support Apple's C dialect as the source language, then APPLE_C should
  79. be undefined).
  80.  
  81. The makefile should be identical to that used by MPW GCC, although you may want to
  82. change the programs' names from "cpp" and "cc1" to something else.  (Yes, cpp
  83. is slightly different for different target machines; for one thing, it has a different
  84. set of predefined symbols.)  The scripts gC and gCPlus invoking the compiler
  85. will also need to be changed as appropriate.  (Giving them different names is a good
  86. idea here too.)
  87.  
  88. RETARGETING TO NEW MACHINES
  89.  
  90. The first thing to do is to study both the GCC manual where it describes how to
  91. retarget, as well as existing machine descriptions, particularly for those machines
  92. with which you are familiar.  Unfortunately, there is no really crystal-clear
  93. description of retargeting anywhere.
  94.  
  95. The easiest approach is to find an existing machine description that is closest
  96. to the one you're interested, build the compiler so you know it will compile and
  97. run correctly, then gradually mutate the description until you're generating code
  98. for your machine.  Many of the more mysterious macros in tm.h are extremely
  99. difficult to write correctly, and if too many are changed all at once, it becomes
  100. well-nigh impossible to discover the cause of a compiler abort.
  101.  
  102. GCC INTERNALS
  103.  
  104. GCC is unusually well-written and well-documented, especially considering the size
  105. and complexity of its intended task.  Nearly all of the machine-independent code
  106. really is machine-independent, although its effectiveness falls off as one gets
  107. further away from the VAX/68K/88K/Mips spectrum of machines and the Unix/Unix-lookalike
  108. spectrum of operating systems.
  109.  
  110. The modifications that were made to get GCC to work under MPW fall into several
  111. categories, each flagged by a distinct preprocessor symbol.
  112.  
  113. MPW is for those changes required by the MPW environment, independent of the compiler
  114. used (typically #includes and file handling).  Most of these occur in contexts where
  115. you'll also see USG (System V Unix), VMS, and MSDOS conditionals.  There are some
  116. MPW_31 conditionals that are imagined (ahem) to work around bugs in MPW 3.1 only.
  117.  
  118. APPLE_C indicates those changes necessary to support Apple's dialect of C, such as
  119. the pascal keyword and direct function definitions.  However, some changes to the
  120. parser have not been so marked (since it gets run through bison).
  121.  
  122. MPW_C is for places in the GCC code that had to be changed to get the MPW C compiler
  123. to handle them correctly.  Some of these are MPW_C31, for bugs that are supposed to
  124. have been fixed in 3.2.
  125.  
  126. APPLE_HAX is for generic changes that would be worthwhile for any version of GCC.
  127. Some of these remove GCC's limitations with respect to the MPW environment, such as
  128. the need to import variables for each function, and work in conjunction with
  129. bits of the target machine description.
  130.  
  131. TROUBLESHOOTING
  132.  
  133. There are two routines crucial to debugging - debug_dump_tree() is a one-argument
  134. function that takes a tree structure and prints it on stderr, while debug_rtx()
  135. does the same for rtl expressions.  These are especially useful to insert just
  136. in front of a call to abort().
  137.  
  138.